dgit.raspbian.org Git - git-annex.git/blob

   1 [[!comment format=mdwn
   2  username="joey"
   3  subject="""comment 2"""
   4  date="2015-09-09T16:36:13Z"
   5  content="""
   6 I can't reproduce that behavior on linux.
   7
   8         joey@darkstar:~/tmp/xx>git annex addurl  --file=annexed file:///./data
   9         addurl annexed (downloading file:///./data ...)
  10         curl: (37) Couldn't open file /data
  11
  12 Here, curl seems to be doing the right thing; the url is not relative; it's
  13 for `/./data`, which doesn't exist.
  14
  15 Relative `file:` urls shouldn't be valid at all, I think?
  16
  17 ---
  18
  19 For checking if a file: url exits, git-annex parses the url and stats
  20 the file itself. The first screenshot
  21 shows this check for file: url existance failing on Windows for
  22 the url `file:///C:/tmp/test/test.dat`
  23
  24 I guess this might come down to problems with parsing file: urls on
  25 Windows; seems especially complicated by drive letters. git-annex and curl
  26 seem to parse this url in different ways.
  27
  28 Checking how that url parses, the uriScheme is "file:" and the uriPath is
  29 "/C:/tmp/test/test.dat". So, it seems clear why it fails to stat that file.
  30
  31 Is there actually a valid way to produce a file: url that refers to a drive
  32 letter? curl seems to think so, since it found the file when `git annex
  33 addurl` ran it. I don't know if the above parse is valid, but it's not
  34 git-annex's code doing the parse, but the URI parsing library.
  35
  36 (Possibly related bug report:
  37 <http://git-annex.branchable.com/bugs/git_annex_test_fails_when_run_through_powershell/>
  38 )
  39 """]]